Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• It looks like the 'libblas' output doesn't have any tests.
• It looks like the 'libcblas' output doesn't have any tests.
• It looks like the 'liblapack' output doesn't have any tests.
• It looks like the 'liblapacke' output doesn't have any tests.
• It looks like the 'blas-devel' output doesn't have any tests.
• It looks like the 'lapack' output doesn't have any tests.

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• It looks like the 'libblas' output doesn't have any tests.
• It looks like the 'libtmglib' output doesn't have any tests.
• It looks like the 'libcblas' output doesn't have any tests.
• It looks like the 'liblapack' output doesn't have any tests.
• It looks like the 'liblapacke' output doesn't have any tests.
• It looks like the 'blas-devel' output doesn't have any tests.
• It looks like the 'lapack' output doesn't have any tests.

Opened an issue upstream for the one remaining windows failure: Reference-LAPACK/lapack#548

3835a4d was an upstream ask for debugging; let's not merge this as is just yet - ideally we can figure out Reference-LAPACK/lapack#548 and backport the patch.

Upstream issue has been fixed, patch backport has been cleaned up, and this is ready for review @conda-forge/lapack.

I dared to add myself to the maintainers, since I'm now already involved in most of the CF blas-stack, but happy to take out that last commit if desired.

Drone just timed out (and is not susceptible to close/open) 😒

drone being difficult...

fatal: unable to access 'https://github.com/conda-forge/lapack-feedstock.git/': Failed to connect to github.com port 443: Operation timed out

@isuruf
What do you think about lapack 3.9.1 - this would be ready? Should mainly be bugfixes, all the real features (AFAICT) were merged only for the upcoming 3.10.0.

Does openblas, mkl suport lapack 3.9.1? If not, we can't merge this.

Thanks @martin-frbg - 3.10.0 will take a while I guess (so no rush for openblas) - however, this PR is just about 3.9.1. 🙃

@conda-forge-admin, please rerender

@isuruf, I'm trying to backport Reference-LAPACK/lapack#597, but it does not apply easily to 3.9.0. I can try to hack something together, but I'd really rather merge this and just delay the MKL 3.9.1 builds (as you did for 3.9.0).

IIRC, 3.9.0 did not take any special measures to ensure some tests are run single-threaded only. So the code you want to patch may not actually be there yet.

IIRC, 3.9.0 did not take any special measures to ensure some tests are run single-threaded only. So the code you want to patch may not actually be there yet.

The issue that Isuru is concerned about - to my understanding - is less about the single threading and more the compatibility with lapack 3.9.1 across the different versions that conda-forge supports. Openblas 0.3.17 obviously does support 3.9.1 already, but MKL doesn't yet.

For 3.9.0, netlib/openblas were published before MKL (from the POV of conda-forge), but since I haven't heard back I'm not sure what other concerns Isuru might have.

Seems this will take a while longer still... MKL decided to skip 3.9.1. and go for 3.10.0 directly.

I still don't understand why we cannot proceed as with 3.9-vs.-3.8, but at this point, I've given up in trying to get an answer on this.

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• It looks like the 'libblas' output doesn't have any tests.
• It looks like the 'libtmglib' output doesn't have any tests.
• It looks like the 'libcblas' output doesn't have any tests.
• It looks like the 'liblapack' output doesn't have any tests.
• It looks like the 'liblapacke' output doesn't have any tests.
• It looks like the 'blas-devel' output doesn't have any tests.
• It looks like the 'lapack' output doesn't have any tests.

Took me a while to pick up this PR after it sat in an echo chamber for so long, but it's green on first push! 🙃

In any case, MKL supports LAPACK 3.10.1 since 2022.2, so does openblas since 0.3.21, and blis thinks they're compatible too, or will at least endeavour to fix issues as they arise.

PTAL @conda-forge/lapack

Have you checked that conda-forge/blas-feedstock#96 works by building this locally?

Have you checked that conda-forge/blas-feedstock#96 works by building this locally?

Given that all implementations claim compatibility, I'm planning to figure this out on the blas feedstock (and would follow up with the respective implementations if they're failing tests or whatever). I don't have the hardware to test this across platforms in advance, and I don't think that's a reasonable bar in this situation?

Once we merge this PR, conda will try to install libblas=3.10.1 because that's the latest version and then users will get the netlib variant which is the only implementation available.

I understand that. Alternatives are pushing this into a dev label (that we can pull in on the blas PR), or to revive conda-forge/blas-feedstock#68 (build all variants including netlib on one feedstock)

Let's push to a rc label

Let's push to a rc label

Done 👍

Thanks

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• travis: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!